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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project: Technical Specification 
Group Services and System Aspects; Telecommunication management, as identified below: 

TS 32.351: "Communication Surveillance (CS) Integration Reference Point (IRP); Requirements"; 

TS 32.352: "Communication Surveillance (CS) Integration Reference Point (IRP); Information Service 

(IS)"; 

TS 32.353: "Communication Surveillance (CS) Integration Reference Point (IRP); Common Object Request 

Broker Architecture (CORBA) Solution Set (SS)"; 

The present document is part of a TS-family defining the Telecommunication Management (TM) of 3G systems. 

The TM principles are described in 3GPP TS 32.101 [1]. The TM architecture is described in 3GPP TS 32.102 [2]. 

The other specifications define the interface (Itf-N) between the managing system (manager), which is in general the 
Network Manager (NM) and the managed system (agent), which is either an Element Manager (EM) or the managed 
NE itself. The Itf-N is composed of a number of Integration Reference Points (IRPs) defining the information in the 
agent that is visible for the manager, the operations that the manager may perform on this information and the 
notifications that are sent from the agent to the manager. Communication Surveillance IRP (CSIRP) is one of these 
IRPs with special function. 

To ensure the availability and reliability of the management, an automatic surveillance of the communication between 
NM and the managed system are required. CSIRP is defined as a capability to achieve this goal. 
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Scope 



The present document defines the Information Service (IS) part of the Communication Surveillance IRP (CSIRP). 
It describes the semantics of the information and the interactions visible across Itf-N in a protocol independent way. 
The information is specified by means of Information Object Classes (lOCs) and the interactions by means of 
operations and notifications. The present document does not specify the syntax (encoding) of the information. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] Void 

[4] 3GPP TS 32.351: "Telecommunication management; Communication Surveillance (CS) 

Integration Reference Point (IRP): Requirements". 

[5] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[6] 3GPP TS 32.312: "Telecommunication management; Generic Integration Reference Point (IRP) 

management: Information Service (IS)". 

[7] 3GPP TS 32.31 1: "Telecommunication management; Generic Integration Reference Point (IRP) 

management: Requirements". 

[8] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[9] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in 3GPP TS 32.101 [1], 
3GPP TS 32.102 [2], 3GPP TS 32.351 [4] and the following apply. 

IRPVersion: See 3GPPTS 32.311 [7]. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CMIP Common Management Information Protocol 

CORBA Common Object Request Broker Architecture 

CS Communication Surveillance 

CSIRP Communication Surveillance Integration Reference Point 

DN Distinguished Name 

EM Element Manager 

IRP Integration Reference Point 

IOC Information Object Class 

IS Information Service 

NE Network Element 

NM Network Manager 

NRM Network Resource Model 



4 System Overview 

4.1 System Context 

The general definition of the System Context for the present IRP is found in 3GPP TS 32.150 [9] subclause 4.7. 
In addition, the set of related IRP(s) relevant to the present IRP is shown in the two diagrams below. 
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Figure 4.1 : System Context A 
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Figure 4.2: System Context B 



4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 
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5 Information Object Classes (lOCs) 

5.1 Information entities imported and local labels 



Label reference 


Local label 


3GPP TS 32.622 [5], information object class, Top 


Top 


3GPP TS 32.622 [5], information object class, iRPAgent 


IRPAgent 


3GPP TS 32.622 [5], information attribute, systemDN 


systemDN 


3GPP TS 32.622 [5], information object class, GenericiRP 


GenericiRP 


3GPP TS 32.312 [6], information object class, ManagedGenericIRP 


ManagedGenericIRP 



5.2 Class diagram 

5.2.1 Attributes and relationships 

This clause introduces the set of Information Object Classes (lOCs) that encapsulate information within the 
IRPAgent. The intention is to identify the information required for the CSIRP implementation of its operations. 
This clause provides the overview of all support object classes in UML. Subsequent clauses provide more detailed 
specification of various aspects of these support object classes. 



«lnformationObjectClass» 
IRPAgent 



«names» 



0..1 



«lnformationObjectClass» 
CSIRP 

+ heartbeatPeriod 
- countDownTimer 
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5.2.2 Inheritance 



« Informat ion Obj ect Class » 
Manag edGeneric I RP 



7\ 



«lnformationC)bjectClass» 
CSIRP 



5.3 



lOCs definition 



5.3.1 CSIRP 



5.3.1.1 



Definition 



This information object represents a capability that can emit heartbeat notification periodically. The emission frequency 
is controlled by an attribute named heartbeatPeriod. The notifications are submitted to NotificationIRP that will 
distribute them to NtfSubscriber(s) according to their related NtfSubscription(s). In addition, the CSIRP provide a 
method for IRPManager to trigger a heartbeat notification at any time. The IOC CSIRP inherits from the IOC 
ManagedGenericIRP specified in 3GPP TS 32.312 [6]. There shall be at most one CSIRP instance per IRP Agent 
instance. 

The heartbeat notifications are submitted via established notification subscriptions, to IRPManagers. The distribution of 
notifications is subject to the status of the related established notification subscription. For example, the IRPManager 
will not be able to receive the heartbeat notification if the notification subscription state is suspended or if the 
notification filter is in effect that discards heartbeat notification. See Annex A for more information. 



5.3.1.2 



Attributes 



Attribute name 


Visibility 


Support Qualifier 


Read Qualifier 


Write Qualifier 


heartbeatPeriod 


+ 


M 


M 


M 


countDownTimer 


- 


M 


- 


- 



5.3.1.3 



Notification 



Name 


Qualifier 


Notes 


notifyHeartbeat 


M 


See clause 6.5.1. 



5.4 



Information attributes definition 



This clause defines the semantics of the Attributes used in Information Object Classes (lOCs). 

5.4.1 Definitions and legal values 



Attribute Name 


Definition 


Legal Values 


heartbeatPeriod 


It specifies the time between two emissions of 
heartbeat notifications. A value of zero implies there is 
no heartbeat emission. The unit is minute. 


Type: Integral numeric value 

Range: value range of heartbeat period is 

from 5min to 60min, is also a legal value. 


countDownTimer 


It represents the current value of a count down timer. 
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6 Interface definition 

6.1 Class diagram representing interfaces 

The following diagram depicts the interfaces of the CSIRP IOC with their corresponding operations. 



«may realize>> 



«lnformationObjectClass» 
CSIRP 



« lnterface» 
CSIRPOperations_2 

+ setHeartbeatPeriodO 



<use» 

\ 

« lnterface» 
CSIRPNoti 1i cat ions 

+ notifyHeartbeatO 



« lnterface» 
CSIRPOperationsJ 



+ get Heartbeat PeriodO 
+ triggerHeartbeatO 



6.2 Generic rules 

Rule 1: each operation with at least one input parameter supports a pre-condition valid_input_parameter which 
indicates that all input parameters shall be valid with regards to their information type. Additionally, each such 
operation supports an exception operation_failed_invalid_input_parameter which is raised when pre-condition 
valid_input_parameter is false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and the 
pre-condition indicates that the operation supports the named optional input parameter. Additionally, each such 
operation supports an exception operation_failed_unsupported_optional_input_parameter_xxx which is raised when 
(a) the pre-condition supported_optional_input_parameter_xxx is false and (b) the named optional input parameter 
is carrying information. The exception has the same entry and exit state. 

Rule 3: each operation shall support a generic exception operation_failed_internal_problem that is raised when an 
internal problem occurs and that the operation cannot be completed. The exception has the same entry and exit state. 
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6.3 Interface CSIRPOperations_1 (M) 

6.3.1 Operation getHeartbeatPeriod (M) 

6.3.1.1 Definition 

IRPManager invokes this operation to obtain the current heartbeat period. 

6.3.1 .2 Input parameters 

There is no input parameter. 

6.3.1 .3 Output parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


heartbeat Period 


M 


CSIRP.heartbeatPeriod 




status 


M 


ENUM (Operation succeeded, Operation failed) 





6.3.1.4 Pre-condition 

There is no pre-condition. 

6.3.1.5 Post-condition 

There is no post-condition. 

6.3.1.6 Exceptions 

There is no exception. 



6.3.2 Operation triggerHeartbeat (M) 



6.3.2.1 



Definition 



The IRPManager invokes this operation to soHcit a notif yHeartbeat notification. After the successful completion 
of the operation, the IRP Agent shall emit the notifyHeartbeat notification as specified in clause 6.4.1 
immediately. One notification shall be emitted as follows: 

a) one notification to the soliciting IRPManager; or 

b) one notification to each of the subscribed IRPManagers. 
If the operation fails the notification shall not be emitted. 

One of the two options above shall be chosen depending on system performance considerations. 

Before invoking this operation, the soliciting IRPManger should make sure it has subscribed the notifyHeartbeat 
notification. 



6.3.2.2 



Input parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


managerldentif ier 


M 


String 


The identifier for the triggering IRPIVIanager. 
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6.3.2.3 



Output parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


status 


M 


ENUM (Operation succeeded, Operation failed) 





6.3.2.4 Pre-condition 

validManagerldentifier. 



Assertion Name 


Definition 


validManagerldentifier 


The input managerldentifier is valid. 



6.3.2.5 Post-condition 

There is no post-condition. 

6.3.2.6 Exceptions 



Name 


Definition 


invalidManagerlden 
tif ier 


Condition: The input parameter of managerldentifier is not valid. 
Returned Information: The output parameter status. 
Exit state: Entry State 
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6.4 Interface CSIRPOperations_2 (O) 

6.4.1 Operation setHeartbeatPeriod (M) 
6.4.1.1 Definition 

The IRPManager invokes this operation to set the heartbeatPeriod. 

As a consequence and indicative of successful completion of the operation the IRP Agent shall emit the 
notif yHeartbeat specified in clause 6.4.1 immediately and continue to emit based on the newly specified 
heartbeatPeriod, to all established notification subscriptions of all subscribed IRPManagers. 

If the heartbeatPeriod specified is the same as the current value in IRP Agent, the operation shall fail. 



6.4.1.2 



Input parameters 



Parameter Name 


Qualifier 


Information Type 


Comment 


heartbeatPeriod 


M 


CSIRP.heartbeatPeriod 





6.4.1.3 



Output parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


status 


M 


ENUM (Operation succeeded, Operation failed) 





6.4.1.4 Pre-condition 

validHeartbeatPeriod AND noconflictingHeartbeatPeriod. 



Assertion Name 


Definition 


validHeartbeatPeriod 


The valid heartbeatPeriod as defined in clause 5.4.1 (Definitions and legal 
values). 


noconflictingHeartbeatPeriod 


The heartbeatPeriod specified is not same as the current value in IRPAgent. 



6.4.1.5 Post-condition 

heartbeatPeriodChanged AND notif yHeartbeatEmitted. 



Assertion Name 


Definition 


heartbeatPeriodChanged 


CSIRP.heartbeatPeriod and GSIRP.countDownTimer are both set to input parameter 
heartbeatPeriod. GSIRP.countDownTimer begins to start counting down. 


notifyHeartbeatEmitted 


CSIRP emits the notifyHeartbeat specified in clause 6.4.1 to all subscribed IRPIVIanagers. 



6.4.1.6 



Exceptions 



■ Name 


Definition ^^^^^^^^^ 


invalidHeartbeatPer 
iod 


Condition: The input parameter of heartbeatPeriod is not within the allowed range. 
Returned Information: The output parameter status. 
Exit state: Entry State 


conf lictingHeartbea 
tPeriod 


Condition: The input parameter of heartbeatPeriod is same as the current value in IRPAgent. 
Returned Information: The output parameter status. 
Exit state: Entry State 
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6.5 Interface CSIRPNotifications (M) 

6.5.1 Notification notifyHeartbeat (M) 



6.5.1.1 



Definition 



The subscribed IRPManager instances are notified that the resources supporting the communication path between the 
Notification IRP Agent and the notification receiving IRPManager are working. 



6.5.1.2 



Input parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M, Y 


CSIRP.objectClass. 


Notification header - see [8]. It shall carry the CSIRP class 
name. 


objectlnstance 


M, Y 


CSIRP. objectlnstance. 


Notification header - see [8]. It shall carry the DN of the 
CSIRP. 


eventTime 


M, Y 


— 


Notification header - see [8]. 


notif icationid 


0, N 


- 


Notification header - see [8]. 


systemDN 


C, Y 


-- 


Notification header - see [8]. 


notif icationType 


M, Y 


"notifyHeartbeat" 


Notification header - see [8]. 


heartbeat Period 


M, N 


CSIRP.heartbeatPeriod 




locator 


M, N 




This parameter, together with the knowledge of Notification 
IRPAgent system internal configuration, can determine the 
communication path used by this notification (see Annex B 
for more information). 

IRPAgent assigns its value. 


triggerFlag 


M, N 


ENUM {IRPManager, 
IRPAgent} 


If this notification is triggered by NM positively by invoking 
"triggerHeartbeat" operation, the value of this parameter 
shall be "IRPManager", otherwise, it shall be "IRPAgent". 


manager Identifier 


M, N 


String 


If the value of triggerFlag is "IRPManager", this field is the 
same as the value of input parameter "managerldentifier" of 
"triggerHeartbeat" operation; 
If the value of triggerFlag is "IRPAgent", this field is null. 



6.5.1.3 



Triggering Event 



6.5.1.3.1 From-state 

heartbeatPeriodCountDownZero OR heartbeatPeriodReset OR heartbeatTriggeredByNM. 



Assertion Name 



Definition 



count DownTimer Zero 



CSIRP. countDownTimer becomes zero. 



CSIRP.heartbeatPeriod is set, to a new or same value, by setHeartbeatPeriod operation. 



heartbeatPeriodReset 



NM invoke "triggerHeartbeat" operation to trigger "notifyHeartbeat" notification positively. 



heartbeatTriggeredByNM 



6.5.1.3.2 To-state 

countDownTimerMayReset . 



Assertion Name 


Definition 


CountDownTimerMayReset 


When this notification is triggered by triggerHeartbeat operation, no effects on 
CSIRP. countDownTimer. 

For normal notifyHeartbeat notification, CSIRP.countDownTimer is set to 
CSIRP.heartbeatPeriod. 
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Annex A (normative): 

IRPAgent behaviour regarding the sending of heartbeat 

notification 

Table A. 1 specifies the IRPAgent behaviour regarding the sending of heartbeat notification in relation to the 
subscribe operation defined in Notification IRP. 

Table A.I : 



1 Subscription 


NotificationIRP supports the emission of heartbeat 


subscribe{ "no notificationCategory specified") 


Send heartbeat and notifications supported by the IRPAgent such 
as notifications defined in Alarm IRP and in BasicCIVI IRP, etc. 


subscribe{ "notificationCategory indicating xxxIRP 
where "xxx" is not "CSIRP" and is "Alarm", 
"BasicCIVI", etc.) 


Send notifications defined in xxxIRP. 


subscribe( "notificationCategory indicating CSIRP") 


Send heartbeat notifications. 


subscribe{ "notificationCategory indicating CSIRP 
and xxxIRP") 


Send heartbeat and notifications defined in xxxIRP. 



Based on table A.l, when IRPManager subscribe 1) PMIRP, CSIRP and 2) BasicCMIRP, AlarmlRP and CSIRP with 
the same manager reference in turn, two subscriptions can only get one notifyHeartbeat notification according to 
definition of subscribe operation in NotificationIRP (3GPP TS 32.302 [8]). 

In case IRPManager would like to receive notifyHeartbeat notification for each subscription, different manager 
reference should be chosen. 
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Annex B (informative): 

Identification of a failed communication path 



B.1 Background 



This discussion is applicable to the CORBA SS (that uses the OMG Notification Service) and other technology that 
uses similar notification technique as the OMG Notification Service. 

For CS IRP to be useful, the IRPManager needs to know: 



ITEM-1: 



ITEM-2: 



The number of communication paths used between the IRPManager and the Notification 
IRP Agent for a particular notification subscription. 

The communication path used by a particular received heartbeat notification. 



If the IRPManager does not have the knowledge of ITEM-1 above, it would not know if it has missed heartbeat 
notifications and therefore, could not detect communication path failure, except the case of all communication paths 
failure. 

If the IRPManager have the knowledge of ITEM-1 but does not have knowledge of ITEM-2, it could detect that there 
has been a communication path(s) failure but would not be able to determine the identity of the failed communication 
path(s). 

To address how IRPManager can have the knowledge of ITEM-1 and ITEM-2, we first characterize all possible 
Notification IRP Agent internal configurations. It is noted that the internal configuration is not a subject for 
standardization. The discussion on system characterization here is to clarify the types of configurations that are 
meaningful to support the current CS IRP specification. 



B.2 Notification IRPAgent Internal Configuration 

We characterize four internal configurations for Notification IRPAgent. 

Config-I: The Notification IRPAgent uses one OMG Notification Channel for all supported 

notif icationCategories. 

Config-2: It uses one OMG Notification Channel for one supported notif icationCategory. For 

example, it uses Channel 1 for Alarm IRP only and it uses Channel 2 for PM IRP only (see 
diagram below). 

Config-3: It uses more than one OMG Notification Channel to support one notif icationCategory. 

Config-4: This is a hybrid of config-1 and config-2. Some OMG Channels are, individually, supporting one 

notif icationCategory while some OMG Channels are, individually, supporting more than 
one notif icationCategory. 
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B.3 The failed communication paths identification 
process 

ITEM-l Knowledge 

The IRPManager should obtain this knowledge at IRPManager and Notification IRP Agent installation times. 
The IRPManager cannot obtain this knowledge via standardized IRP operation at run-time. 

ITEM-2 Knowledge 

Config-1: 

When IRPManager has successfully subscribed for heart beat, the IRPManager expects 1 heartbeat per heartbeat 
period. Absence of heartbeat during the heartbeat period plus IRP Agent knowledge of its own configuration 
allows IRP Agent to determine the communication path that has failed. 

The IRP Agent shall use the locator parameter and the locator parameter may contain no information. 

Config-2: 

When IRPManager has successfully subscribed for heart beat, the IRPManager expects n heartbeat per heartbeat 
period. The IRPManager knows the value of n because n equals to the number of 

notif icationCategories subscribed. When IRPManager receives less than n heartbeat per heartbeat 
period, it knows the exact number but not the identification of the failed communication path(s). The received 
locator values received and the IRP Agent knowledge of the Notification IRP Agent internal configuration 
enables the identification of the failed communication path(s). 

For example, the IRP Agent pushes notif yHeartbeat with locator="channel 1" on CP-Al and CP-Bl 
and pushes locator="channel 2" on CP-B2 and CP-A2. When IRPManager-B, using subscription ID=3 and 
expecting two heartbeats per period, receives one notif yHeartbeat , detects/knows that one 
communication path has failed. The entity that knows: 

(a) The locator (say =="channel 1") of the received notif yHeartbeat 

(b) The subscription ID involved and 

(c) The IRP Agent knowledge of the Notification IRP Agent system configuration 

will be able to identify the failed communication path (i.e. in this case, CP-B2). 

The IRP Agent shall use the locator parameter. The value of "channel 1" is an example. IRP Agent could 
choose any other identification. 

Config-3 and config-4: 

There is no recommendation on how IRPManager can obtain answers for ITEM-l and ITEM-2. This is for 
further study. 

The information provided through the locator parameter (empty, content) does not indicate the used configuration. 
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Figure B.1: Hypothetical IRPAgent internal configuration supporting CS IRP 
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